Michael B. Dilger <dilger@CS.UCDAVIS.EDU> wrote: >Scott Barman <scott@Disclosure.COM> writes: >> It limits the attackable objects to one item, which can be secured far >> better than the program plus EIGHT libraries currently being used by the >> Solaris 2.4 login program. What's easier to tie down, nine items or one? > >You're counting backwards. Would you rather have 10 seperately programmed >seperately compiled authentication modules (one for login, one for ftp, >etc), or just one in a _shared_ library? Not quite. You _have_ to protect login, ftp, telnet, ... because otherwise someone can just replace the executable. With shared libraries you _also_ have to worry about the shared libraries. The effort required to protect the system is increased by the number of shared libraries required. In the case of Solaris 2.4, /bin/login has 8 shared libraries, ftp and telnet have 6. This means you have to protect the 10 (or whatever) executables _and_ the 8 shared libraries they use. OTOH, having all the authentication code in one shared place would be of benefit in terms of replacing the authentication code with something different (and potentially stronger). If it was just one authentication library, and the location of the library was hard-coded in the executable and couldn't be over-ridden, it might be OK. There are advantages and disadvantages to shared libraries. In some cases, a dynamically linked executable is more appropriate, in other cases a statically linked executable is more appropriate. Unfortunately, Sun have chosen to not allow us that choice. Peter --- Peter Jeremy (VK2PJ) jeremyp@gsms01.alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 690 5247